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DETAILED ACTION 

1 . This communication is responsive to the Amendment filed 1 8 July 2006. 

2. Claims 6-18. 20 and 23-37 are pending in this application. Claims 6, 8, 10, 11, 
12, 15, 18 and 23 are independent. In the Amendment filed 1 8 July 2006, claims 1 9 
and 21-22 have been cancelled and claims 6, 8, 12. 18, 20 and 35 have been amended. 
This action is made Non-Final. 

3. The rejections of claims 6-37 as being anticipated by US Patent No 6,233,585 to 
Gupta et al have been withdrawn as necessitated by the amendment. 

SpBoificaiion 

4. The objection to the abstract is withdrawn as necessitated by the amendment. 

Claim Rejections - 35 USC § 101 

5. The rejections of claims 6-9, 12-14 and 18-37 under 35 U.S.C. 101 are 
withdrawn as necessitated by the amendment. 

Claim Rejections - 35 USC § 102 

6. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that 
form the basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(b) the invention was patented or described in a printed publication in this or a foreign country or in public 
use or on sale in this country, more than one year prior to the date of application for patent in the United 
States. 
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7. Claims 6, 8, 10, 11, 12 and 15 are rejected under 35 U.S.C. 102(b) as being 
anticipated by the article "Transaction Scheduling in Dynamic Composite 
Multidatabase Systems" to Bradshaw et al (hereafter Bradshaw et al). 

Referring to claim 6, Bradshaw et al disclose a data management system, said 
system characterized as a composite system comprising at least one processor (see 
abstract), the system comprising 

a plurality of processes [multidatabase servers run as separate processes or as a 
separate group of processes] (see section 3: Composite Multidatabase Model, lines 10- 
16); 

each process having an Interface and implementing at least one respective 
service defined by that interface (see section 3: Composite Multidatabase Model, lines 
1-7); 

a first invocation of the at least one respective service by a transaction resulting 
in the creation of a first transaction local to the process thereof, the first local transaction 
being a child of the invoking transaction [Tk] and being parent [Tkl-q] of any transaction 
triggered by invocation of a service of another process (see section 3: Composite 
Multidatabase Model, lines 86-90); 

a second invocation of the at least one respective service by a transaction 
resulting in the creation of a second transaction local to the process thereof, the second 
local transaction being a child [Tk] of the invoking transaction and being parent [Tkl-q] 
of any transaction triggered by invocation of a service of another process (see section 3: 
Composite Multidatabase Model, lines 86-90); 
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each process characterized in that if the first transaction and the second 
transaction conflict but are both children of a same invoking transaction, then the first 
transaction and the second transaction are not executed concurrently [one transaction 
must commit or abort before the other transaction executes] (see section 5.1 : 
Composite Rigorous Scheduling Algorithm, lines 4-9); 

each process further characterized in that each transaction local thereto is 
independently handled at the process [M2 handles Tk] (see section 3: Composite 
Multidatabase Model, lines 86-90); 

each process making scheduling and recovery decisions independent of any 
centralized component (see section 5: Scheduling Transactions in Composite 
Multidatabase systems, lines 18-20 - each component keeps rigorous histories). 

Referring to claim 8, Bradshaw et al disclose a data management system, said 
system characterized as a composite system comprising at least one processor (see 
abstract), the system comprising 

a plurality of processes [multidatabase servers run as separate processes or as a 
separate group of processes] (see section 3: Composite Multidatabase Model, lines 10- 
16); 

each process having an interface and implementing at least one respective 
service defined by that interface (see section 3: Composite Multidatabase Model, lines 
1-7); 
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invocation of the at least one respective service by a thread of the invoking 
transaction and being parent of any transaction triggered by invocation of a service of 
another process (see section 3: Composite Multidatabase IVIodel, lines 86-90); 

each process further characterized in that each transaction local thereto is 
independently handled at the process (see section 3: Composite Multidatabase Model, 
lines 86-90); 

each process making scheduling and recovery decisions independent of any 
centralized component triggered by invocation of a service of another process, each 
process further characterized in that each transaction local thereto is independently 
handled at the process, each process making scheduling and recovery decisions 
independent of any centralized component (see section 5: Scheduling Transactions in 
Composite Multidatabase systems, lines 18-20 - each component keeps a rigorous 
history),the method comprising the steps of: 

propagating from a first process to a second process a message indicative 
of a globalCommit operation with respect to a root transaction, said message 
also indicative of a number or identifying list of invocations which the first process 
has made to the second process on behalf of the root transaction (see section 2: 
Related Work, column 3); 

within the second process, comparing the number or list indicated in the 
message with a count or list within the second process of the number or list of 
invocations which have been made on behalf of the root transaction (see section 
2: Related work, column 3); 
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in the event the comparison yields a non-match, aborting the transaction 
[if orders are not consistent then the transaction aborts] (see section 2: Related 
Work, lines 15-17). 

Referring to claim 10, Bradshaw et al disclose a method for use with a data 
management system, said system characterized as a composite system (see abstract), 
the system comprising a plurality of processes, each process having an interface and 
implementing at least one respective service defined by that interface, invocation of the 
at least one respective service by a transaction resulting in the creation of a transaction 
local to the process thereof, the local transaction being a child of the invoking 
transaction and being parent of any transaction triggered by invocation of a service of 

■ 

another process, each process further characterized in that each transaction local 
thereto is independently handled at the process, each process making scheduling and 
recovery decisions independent of any centralized component (see abstract), the 
method comprising the steps of: 

propagating from a first process to a second process a message indicative of a 
globalCommit operation with respect to a root transaction, said message also indicative 
of a number or list of invocations [multicellular commit order list] which the first process 
has made to the second process on behalf of the root transaction (see section 5.2: 
Composite Timestamp Ordering Algorithm); 

within the second process, comparing the number or list indicated in the 
message with a count or list within the second process of the number or list of 
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invocations which have been made on behalf of the root transaction (siee section 5.2: 
Composite Timestamp Ordering Algorithm); 

in the event the comparison yields a match, proceeding with the globalCommit 
operation [receives the commit] (see section 5.2: Composite Timestamp Ordering 
Algorithm); 

Referring to claim 11, Bradshaw et al disclose a method for use with a data 
management system, said system characterized as a composite system (see abstract), 
the system comprising a plurality of processes, each process having an interface and 
implementing at least one respective sen/ice defined by that interface, invocation of the 
at least one respective service by a transaction resulting in the creation of a transaction 
local to the process thereof, the local transaction being a child of the invoking 
transaction and being parent of any^transaction triggered by invocation of a service of 
another process, each process further characterized in that each transaction local 
thereto is independently handled at the process, each process making scheduling and 
recovery decisions independent of any centralized component (see abstract), the 
method comprising the steps of: 

propagating from a first process to a second process a message indicative of a 
globalCommit operation with respect to a root transaction, said message also indicative 
of a number or list of invocations [multicellular commit order list] which the first process 
has made to the second process on behalf of the root transaction (see section 5.2: 
Composite Timestamp Ordering Algorithm); 
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within the second process, comparing the number or list indicated in the 
message with a count or list within the second process of the number or list of 

invocations which have been made on behalf of the root transaction (see section 5.2: 
Composite Timestamp Ordering Algorithm); 

in the event the comparison yields a non-match, aborting the transaction [if the 
orders do not match then they are aborted] (see section 2: lines 15-17 and section 5.2: 
Composite Timestamp Ordering Algorithm); 

Referring to claim 12, Gupta et al disclose a distributed system, said system 
characterized as a composite system comprising at least one processor (see abstract), 
the system comprising 

a plurality of processes [multidatabase servers run as separate processes or as a 
separate group of processes] (see section 3: Composite Multidatabase Model, lines 10- 
16); 

each process having an interface and implementing at least one respective 
service defined by that interface (see section 3: Composite Multidatabase Model, lines 
1-7); 

each or any globalCommit message exchange between processes also carrying 
information about the actual work being committed [the globalCommit is tagged with a 
timestamp] (see section 5.2: Composite Timestamp Ordering Algorithm, lines 27-30). 

Referring to claim 15, Gupta et al disclose a method for use in a distributed 
system, said system characterized as a composite system, the system comprising a 
plurality of processes, each process having an interface and implementing at least one 
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respective service defined by tliat interface (see abstract), the method comprising the 
step of: 

for each globalCommit message exchanged between processes, including also 
information about the actual work being committed [the globalCommit is tagged with a 
timestamp] (see section 5.2: Composite Timestamp Ordering Algorithm, lines 27-30). 

8. Claims 7, 9, 13, 14, 16 and 17 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over the article 'Transaction Scheduling in Dynamic Composite 
Multidatabase Systems" to Bradshaw et al (hereafter Bradshaw et al) as applied 
respectively to claims 6, 8, 12 and 15 above, and further in view of US Patent No 
6,233,585 to Gupta et al (hereafter Gupta et al). 

Referring to claim 7, Bradshaw et al disclose a root transaction. However, 
Bradshaw et al fail to explicitly disclose the further limitation wherein the root transaction 
is able to dynamically set concurrency preferences for the resulting distributed 
transaction, based on client needs. Gupta et al discloses a transaction system (see 
abstract), including the further limitation wherein the root transaction is able to 
dynamically set concurrency preferences for the resulting distributed transaction, based 
on client needs (see column 5, line 61 - column 6, line 3 - the isolation level selected is 
considered to represent the concurrency preference) in order to provide improved 
customization. 
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It would have been obvious to one of ordinary skill in the art at the time of the 
invention to use the feature of dynamically setting concurrency preferences with the 
system of Bradshaw et al. One would have been motivated to do so in order to provide 
improved customization. 

Referring to claim 9, Bradshaw et al disclose a root transaction. However, 
Bradshaw et al fails to explicitly disclose the further limitation wherein each process is 
built using Java. Gupta et al discloses a transaction system (see abstract), including 
the further limitation wherein each process is built using Java (see column 13, lines 1-6) 
so since Java is a commonly used language. 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to use the feature of each process being built using Java as disclosed by with 
the root transaction of Bradshaw et al. One would have been motivated to do so since 
Java is a commonly used language. 

Referring to claim 13, Gupta et al disclose the system of claim 12, such 
information being logged for recoverability in the event of a crash, such information 
being used for assistance at any time before, during or after global commitment (see 
column 11, lines 12-21). 

Referring to claim 14, the combination of Bradshaw et al and Gupta et al 
(hereafter Bradshaw/Gupta) discloses the system of claim 12 or 13, wherein any 
globalCommit requires a registration, and wherein the registration for a globalCommit 
also carries information about the actual work being committed (Gupta et al: see column 
11. lines 12-21). 
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. Referring to claim 16, Bradshaw et al disclose a composite system. IHowever, 
Bradshaw et al fail to explicitly disclose the further step of logging such information for 
recoverability in the event of a crash, such information being used for assistance at any 
time before, during or after global commitment. Gupta et al discloses a transaction 
system (see abstract), including the further step of logging such information for 
recoverability in the event of a crash, such information being used for assistance at any 
time before, during or after global commitment (see column 11, lines 12-21) in order to 
improve recoverability of the information. 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to use the feature of logging information as disclosed by with the system of 
Bradshaw et al. One would have been motivated to do so in order to improve 
recoverability of the information. 

Referring to claim 17, Bradshaw/Gupta discloses the method of claim 15 or 16 
further comprising the step of propagating a registration for a globalCommit, wherein the 
registration for a globalCommit also carries information about the actual work being 
committed (Gupta et al: see column 1 1 , lines 1 2-21 ). 
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9. Claims 18, 20 and 23-37 are rejected under 35 U.S.C. ip3(a) as being 
unpatentable over the article "Transaction Scheduling in Dynamic Composite 
Multidatabase Systems" to Bradshaw et al in view of US Patent No 6,233,585 to 
Gupta et al. 

Referring to claim 18, Bradshaw et al disclose a distributed system, said system 

* 

characterized as a composite system (see abstract), the system comprising 

a plurality of processes [multidatabase servers run as separate processes or as a 
separate group of processes] (see section 3: Composite Multidatabase Model, lines 10- 
16); 

each process having an interface and implementing at least one respective 
service defined by that interface (see section 3: Composite Multidatabase Model, lines 
1-7); 

However, Bradshaw et al fail to explicitly disclose the further limitations of the 
root invocations. Gupta et al discloses a transaction system (see abstract), including 
the further limitations wherein the root invocation or, alternatively, the root's human user 
is allowed to dynamically set its/his concurrency preferences for the entire invocation 
(see column 12, lines 30-32); wherein the root invocation [transaction] propagates the 
concurrency preferences with each or any child invocation it makes (see column 12, 
lines 46-50) in order to provide improved customization; wherein the propagated 
concurrency preferences at any level in the root invocation's invocation hierarchy 
specify the extent to which shared resource access is desired or allowed or denied 
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among descendant invocations of the root invocation or user and other, concurrent 
invocations who are also descendants of the same root (see column 12, lines 46-50). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to use the features of the root transactions with the system of Bradshaw et al. 
One would have been motivated to do so in order to provide improved customization. 

Referring to claim 20, Gupta et al disclose the system of claim 19 wherein each 
invocation propagates the concurrency preferences as it has received them from the 
root invocation (see column 12, lines 46-50). 

Referring to claim 23, Bradshaw et al disclose a data management system, 
referred to as service, comprising: 

One or more operations that can be invoked by remote clients [multidatabase 
servers run as separate processes or as a separate group of processes] (see section 3: 
Composite Multidatabase Model, lines 10-16); 

Some or all such remote clients having one or more associated contexts or 
transaction contexts (see Fig 2). 

However, Bradshaw et al fail to explicitly disclose the further limitations. Gupta et 
al discloses a transaction system (see abstract), including the further limitations of an 
invocation by a remote client also containing partial or complete information indicating 
or containing said client's context or contexts (see column 8, lines 10-51); an invocation, 
by a remote client, of an operation leading to a new transaction different from, but 
possibly related to, any existing client transaction (see column 5, lines 16-19); such an 
operation-level transaction being committed before the client context is terminated 
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before globalCommit notification (see column 12, lines 28-57); the service maintaining 
an undo operation for such a committed operation (see column 6, lines 12-20); a failing 
or failed remote client context leading to the execution of the undo operations of the 
corresponding committed invocations in the service (see column 7, lines 42-46) in order 
to provide recoverability. 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to use the feature of undo operations as disclosed by Gupta et al with the 
management system of Bradshaw et a!.. One would have been motivated to do so in 
order to provide recoverability. 

Referring to claim 24, Bradshaw/Gupta discloses the system of claim 23 where 
some or all undo operations are executed in an order that is the reverse of the order of 
their original counterparts (Gupta et al: see column 9. line 66 - column 10, line 2 - 
rollback is considered to represent undo; first-in-last-out is considered to represent 
reverse order). 

Referring to claim 25, Bradshaw/Gupta discloses the system of claim 23 where 
in addition the undo operations are chosen or defined in the same system as the one 
where the corresponding normal operations were executed (Gupta et al: see column 12, 
lines 46-56). 

Referring to claim 26, Bradshaw/Gupta discloses the system of claim 23 where 
some or all undo operations are unknown to a remote client or its context (Gupta et al: 
see column 12, lines 11-12). 
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Referring to claim 27, Bradshaw/Gupta discloses the system of claim 23 where 
some or all undo operations are executed after a timeout and independent of whether 
the client's context outcome requires such undo (Gupta et al: see column 12, lines 11- 
12). 

Referring to claim 28, Bradshaw/Gupta discloses the system of claim 23 where 
an undo operation's effects are confined to the data managed by the service on which 
the undo operation is maintained, even if the original operation involved other services 
(Gupta et al: see column 12, lines 45-56). 

Referring to claim 29, Bradshaw/Gupta discloses the system of claim 23 where 
the service keeps locks to ensure that undo operations can be executed correctly 
(Gupta et al: see column 9, lines 19-21). 

Referring to claim 30, Bradshaw/Gupta discloses the system of claim 23 where 
client context-related information is also part of any global commit message exchanges 
(Gupta et al: see column 10, lines 4-7). 

Referring to claim 31, Bradshaw/Gupta discloses the system of claim 23 where 
client context information includes application-specific data (Gupta et al: see column 10, 
lines 4-7 - the context relates to the transaction which is considered to be application- 
specific). 

Referring to claim 32, Bradshaw/Gupta discloses system of claim 31 where all 
or part of the context information is logged, i.e. stored on persistent storage, and 
retrievable by a human. Administrator (Gupta et al: see column 8, lines 11-14). 



Application/Control Number: 10/707.644 Page 16 

Art Unit: 2167 

Referring to claim 33, Bradshaw/Gupta discloses system of claim 23 where the 
service accepts messages indicative of which previously committed operations have to 
be undone (Gupta et al: see column 11. lines 1-7). 

Referring to claim 34, Bradshaw/Gupta discloses system of claim 23 where the 
service accepts messages indicative of which previously committed operations do not 
have to be undone (Gupta et al: see column 1 1 , lines 1-7). 

Referring to claim 35, Bradshaw/Gupta discloses the system of claim 23 where 
some or all invocations are message-based or asynchronous (Gupta et al: see column 
3, lines 1-4). 

Referring to claim 36, Bradshaw/Gupta discloses system of claim 23 where 
some or all invocations are synchronous (Gupta et al: see column 3, lines 1-4). 

Referring to claim 37, Bradshaw/Gupta discloses system of claim 23 where the 
client can request the undo executions of its invocations at the service while still 
allowing globalCommit in the end (Gupta et al: see column 12, lines 28-56). 
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